在istio使用後,為了因應服務網格中的各種情況,我們需要一個能知道服務狀態的機制來幫助我們管理服務。這時可以透過sidecar進行各種可觀測性,包括:
Metric: istio 根據四個指標,包括請求的延遲、經過系統的流量、經過系統的錯誤與資源利用的飽和度
Distributed Traces: istio 可以紀錄請求在每個節點上服務的訊息,並提供請求路徑與延遲的可視化
Access Logs: istio 提供一組可設定的格式,用來產生經過服務流量的Access Logs,以此紀錄各種訊息
istio 提供的觀測性功能,我認為是蠻全面的,要全部都嘗試過會是一大工程,所以各位根據各種需求可以去找尋對應的解決方案,今天就先用isito中最簡單的紀錄日誌功能-Access Logs來給各位看效果
當我們在安裝istio時,profile=demo就預設有啟動Access Logs了,除非安裝時使用其他profile 不然不用多作其他配置。
kubectl apply -f samples/sleep/sleep.yaml
apiVersion: v1
kind: Service
metadata:
  name: helloworld-service
spec:
  type: ClusterIP
  selector:
    app: helloworld
  ports:
    - protocol: TCP
      name: http
      port: 5000
      targetPort: 5000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld-v1
  labels:
    app: helloworld
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloworld
      version: v1
  template:
    metadata:
      labels:
        app: helloworld
        version: v1
    spec:
      containers:
      - name: helloworld-v1
        image: allenku0/hello-api:v1
        ports:
        - containerPort: 5000
        resources:
          limits:
            cpu: 500m
          requests:
            cpu: 200m
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld-v2
  labels:
    app: helloworld
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloworld
      version: v2
  template:
    metadata:
      labels:
        app: helloworld
        version: v2
    spec:
      containers:
      - name: helloworld-v2
        image: allenku0/hello-api:v2
        ports:
        - containerPort: 5000
        resources:
          limits:
            cpu: 500m
          requests:
            cpu: 200m
export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
kubectl exec "$SOURCE_POD" -c sleep -- curl -sS -v http://helloworld-service:5000/api/details

4. log 結果
kubectl logs -l app=sleep -c istio-proxy

透過以上可以知道sidecar 會幫我們紀錄經過的流量,包括outbound、status code等,可以以此作為服務檢查的依據,當然者只是最基本的功能,可以簡單紀錄服務的流量狀態。
今天就到這邊,我們明天再見!